Extract package fetching logic into shared utility #130
Conversation
g-elwell
force-pushed
the
fix/extract-package-fetching
branch
from
fc8702c to
385bbb5
Compare
This comment was marked as resolved.
This comment was marked as resolved.
We can ignore #119 for the time being, and I'm unsure of when or if #101 will be added - a lot has changed since.
This wasn't intentional and the behaviour you're trying to get here is what is needed, so the ideas and direction work. Code just needs reviewing and testing. |
g-elwell
force-pushed
the
fix/extract-package-fetching
branch
from
385bbb5 to
248127d
Compare
|
@ampersarnie this is now ready, thanks! I think there's potential to improve it in future, but I've purposefully left the extracted utility as close as possible as it was in the |
Description
This PR extracts the logic for fetching and validating packages into a shared utility which can be used by any commands.
Previously this was implemented in two locations, with more on the way in #101 and #119. Repeating this logic is complicated and prone to errors due to the various scenarios and validation required to gather a list of build-tools-compatible packages to run a command against.
This change fixes a potential bug where the
ciandinstallcommands would try to run against unexpected packages (e.g: plugins with apackage.jsonbut nosrc/entrypoints). I am unsure whether this was intentional, as although an entrypoint is not required to runnpm install, we enforce the entrypoint directory structure in our projects and use this to differentiate them from other packages that may exist in a workspace. I don't think the build tools should be concerned with packages that don't meet this criteria as the results could be unexpected.Before
After